|
This article was contributed by Doug Howat in July 2017. It is presented exactly as submitted to CCH. * On 1st March 1965 I started work as a trainee computer operator on the Cadbury Orion computer and it snowed hard at lunchtime. I don’t think these two events were related. At this time I should have been near the end of my final year at university, but health issues arose just as the academic year started and although I was fully recovered by early 1965 it was too late to resume my studies that year. If you lived in south-west Birmingham at that time and wanted some temporary employment the obvious two names were Cadburys and “The Austin”. “The Austin” had nothing at all and I had worked at Cadburys earlier in my student holidays, on the night shift, filling Cadburys Contrast boxes and cellophaning cartons of Cadburys Roses; it was OK for a few weeks but I didn’t feel like doing that again for six months. I went for an interview with them on 25th February to see if they had anything : nothing.
I’d just about got home when Cadburys phoned to say that they now had a vacancy for a computer operator and would I be interested ? Now let’s just put that into perspective. This was a time when computers were just starting to make a major impact into business : IBM had launched it’s IBM System/360 range the previous year and other manufacturing companies were getting into the act themselves, or at least trying to. To a young technically-minded nerd like me these were incredible machines which would soon have the power to take over the world and many people were deeply suspicious of them : “they’ll have all our jobs in a few years - just you wait and see”. (In view of some of the IT disasters that I’ve worked on in the ensuing years this optimism seems somewhat laughable now.)
Of course, computers then were vast expensive things requiring extensive air-conditioning to keep them cool, and only large organisations could afford them. The average nerd like me had no hope of ever getting near one apart perhaps from at a trade exhibition though we were fascinated - some might say obsessed - by these machines. If you knew the difference between an AND-gate and an OR-gate you were clever, if you could draw the circuit diagram of either (transistors, diodes, resistors) you were a computer expert, if you’d actually built an AND-gate and demonstrated it’s action you were a total genius. I had, in fact, done all those things but I never saw myself as anything other than a rather sad lonely experimenter who liked playing with electronics (and no-one ever seemed to know quite how you took a load of AND or OR gates and actually made them do anything useful ... like adding two numbers together, let alone printing a document).
So I went back to Cadburys the following morning and had an interview with Leighton Jones, the computer manager (I think he was “D.P. Manager” - the phrase “I.T.” didn’t, I think, come into use until the early 1980s). He quizzed me about my background and aspirations and also about my hobbies. After I told him about AND-gates and OR-gates etc. he said “well I think you know more than I do - when can you start ?” As it was now Friday morning I suggested the following Monday and he agreed. I still couldn’t quite see how AND-gates etc. came into the actual operating but this was agreed - and I had absolutely no idea what all this would all eventually lead me to.
And so on that snowy Monday I was duly welcomed and taken into the hallowed sanctuary that was the computer room itself where I met most of the other operators : Colin Chinnery was the Head Operator and I recall a John, a Liz and a diminutive Pam. The actual machine was in one big room with three three smaller offices opening along an outside wall. The middle one was the operators rest room, one may have been Colin’s office though I seem to remember a Marjorie who was somehow involved in it all. The third, and largest, of these side rooms was the engineers room and although I didn’t at once realise the significance of having such people around their presence soon became clear.
The computer itself was - obviously - made up of many parts and I was duly shown each of these. The actual processing parts were all in one vast assembly - probably about twenty feet wide, six high and maybe three feet deep. There were impressive door on each of bays of equipment - they looked like doors from expensive cars and even had similar handles. Inside most were racks of plug-in printed circuit boards, a few dozen on each row and many rows stacked one above another. The entire assembly could be swung out on hinges to reveal an intricate mass of multicoloured wires which connected the myriad circuit board connections to each other. One door gave access to three magnetic drum assemblies which provided additional storage for programs to use (I think) and I have a vague memory that these required an amazingly long time to spin up to, and stabilise at, their operating speed : an hour and a half comes to mind. I think they each had a capacity of 16k (though that was presumably 16k Orion words i.e. 16,000 times six 8-bit bytes in more modern terms; one Orion word had 48 bits.)
The back of this whole assembly also had doors, many opening to reveal further racks of circuit boards, but one held the main memory : three banks of 4k each. I seem to remember that domestic fan, standing on a small table and pointing at them, was kept permanently on to provide additional cooling for these. Each 4k bank was about the size of a shoebox and on one occasion I was permitted to look inside one, presumably when it was open for maintenance. There are plenty of photos available of such a “core memory” which used minute ferrite rings about 3-4mm in diameter strung on wires stretched across solid frames; multiple frames were stacked above each other. So you could actually SEE each individual bit of storage ... nowadays my camera has a 64 gigabyte memory in a chip about the size of my thumbnail !
Another thing I was shown were the seven tape drives referred to as “MTA, “MTB”, up to “MTG”. These were about the size of the old weighing machines where you stood on the front, put a coin in a slot, and a dial went round and - if you were lucky - a recorded voice spoke your weight and a card popped out of a slot with your weight printed on it. They used 1-inch wide magnetic tape and the feed and take-up mechanisms used vacuum servos whose chambers required cleaning daily with (I think) iso-propanol and the proverbial lint-free cloth. The tape spools themselves lived in lockable round plastic containers when not in use and there was always a rack of tapes on a trolley nearby.
There were also two paper-tape punches, two paper tape readers (one on a free-standing cabinet, the other on the control desk), one clunky punched card reader and two massive printers.
However, the thing that really showed was the control desk which looked exactly how the computer-fascinated nerds like me always imagined a computer would look like. A wide desk, back with a sloping panel which carried a huge array of switches, buttons, knobs and flashing display lights. The left-hand section was a block diagram of some part of the main processor and there were dozens of multi-coloured lamps that illuminated when that part of the system was doing something. Virtually all these controls and displays were for the engineers use only, and in fact most of the knobs were inactive in normal operations. That didn’t stop us operators - when a cluster of goggle-eyed kids (or adults) was watching through the observation window - from pressing the multi-coloured buttons, noting the display lamps, typing messages on the Flexowriter, and generally looking knowledgeable - in reality a completely pointless exercise as we were actually doing nothing useful at all, but maybe it impressed the onlookers !
The Flexowriter was, of course, our only way of telling the computer what to do, and knowing what it was actually WAS doing at any time (not always quite what we expected ...). To input a command we pressed a switch on one side of the Flexowriter and (I think) a light came on while we typed - pressing the RETURN key ended the command. Everything we typed came out in red while the Orion always printed in black. One possible command was “SPACE” (abbreviated to “SPA” in actual use) which was the way of finding out what core and drum space was available and also what peripheral devices were free (remember : what I typed is in red) :
So we knew what core and drum storage was available, and also that tape drives MTA, MTB and MTD, both paper tape readers, the card reader, paper tape punch A and line printer B were available for use by any program that needed them.
The Orion printed the time every minute and the date as well every ten minutes : a time is shown above.
There was a single door to the computer room and on the floor outside it was something called (something like) a “Tak-Mat”. This consisted of a solid base above which were many layers of some fabric which were impregnated with some sticky compound - you had to walk over this to enter the room and the idea was to remove loose dirt from the underside of our shoes. These sheets were tucked in above the base in the manner of bed sheets and blankets above a mattress. After a few days the whole thing became revolting, with all sorts of unidentified gunge stuck to it so the most junior operator - i.e. now me - had the job of removing the top fabric layer and disposing of it in a bin outside. Then you had to spend five minutes washing your hands in the Gents (the lowly one of these : there was another Gents adjacent very prominently labelled “Staff A & B” which we were not supposed to use, though I don’t know what penalty applied if we ever did. Nor do I know what may have happened to any other loose dirt we might be carrying e.g. on the sides and top of our shoes, not to mention anywhere else).
But the one thing that stands out in my memory of those days was the sheer NOISE in the computer room - I suspect that ‘Elfin Safety bods nowadays would insist on us wearing ear protectors. There was a constant background roar from the air-conditioning as well as numerous cooling fans inside the computer cabinets themselves. I don’t recall what noise the tape drives made but the card reader made a massive mechanical clatter and the two paper tape punches produced a high-pitched buzzing rattle when in use. Worst of all, though, were the two Analex line printers in each of which a row of 120 hammers banged forward to hit the printed document and a ribbon against a fast-rotating drum which had the character set embossed on it. At times it sounded like machine-gun fire. I seem to recall once reading the instructions for moving the printing assembly on one of these devices - it started something like this :
“This requires two 8-foot scaffold poles, one each to be pushed through the lifting holes at the front and back of the printer; also four men each capable of easily lifting 100lbs.”
And that was just the printing assembly : the electronics was in a huge cabinet underneath. In 2017, if you want a new printer for your home computer you visit PC World and walk out with a box under one arm - and it’ll probably do photocopying and document scanning as well !
Conversing across the computer room meant shouting - loudly at times - and it was easy to miss-hear something. An operator standing by the flexowriter might see a message requiring a tape to be loaded or un-loaded on a particular tape drive but with the letters “B”, “C”, “D”, “E” and “G” sounding so similar it was entirely possible to hear wrong and and press the Load or Unload button on the wrong drive - usually with disastrous results.
The other thing that it’s impossible to forget is the sheer unreliability of the entire computer, compared with what we expect today. “Mean Time Between Failures” was measured in terms of days, or sometimes hours, and there were days when we operators had almost nothing to do, and just sat in our rest room while the engineers wheeled up oscilloscopes and other test gear and worked inside on one of those racks of electronics. They had some sort of diagnostic tool which they used on these occasions - it seemed to be a continuous loop of 7-track paper tape which ran constantly through on of the tape readers and, presumably, tested different bits of the machine. The speaker was always turned on for this and I recall a repeating series of harsh tones, starting high and gradually dropping in pitch before starting again; the nearest thing I’ve ever come across since is the sound of a dial-up modem “handshake” when connecting to a remote computer in pre-cable internet days.
These breakdowns must have been a constant source of worry as the regular work was regularly disrupted. We were not alone in this and most organisations with a computer had an agreement with some other (preferably local) business which had the same type of machine; when one computer broke down the operators would decamp to the other company - usually in the middle of the night - to carry out the required processing. This assumed, of course, that the other machine was itself working ! My first experience of this was on my first day there : the computer ceased working after lunch and was still non-operational the next day. Colin and I loaded up a car with trays of punched cards, magnetic tapes and stationery, and drove down to the ICT Bureau in Newman Street, central London. In pre-M40 and pre-M42 days this entailed driving to and around Coventry and then taking the M45 down onto the M1. We spent the afternoon there and drove back, in a blizzard, and with numerous traffic delays.
Three weeks later a similar thing happened and after a day with no computer we again drove down to Newman Street where we were given access to the Orion from 10:30PM until 5:30AM next day - even there we had problems : the paper tape punch kept giving errors. We got back to Bourneville at 9AM, having worked (or at least tried to) for almost 24 hours, not to mention driving about 200 miles - I’m not sure what the “Working Time Directive” would have said about that.
The actual alternative Orion for us was in fact at the Metal Box Company in Worcester and I don’t know why we went to London that day, but in late June I did spend a night in Worcester with a couple of other Cadbury people after a full day was lost at Bourneville. I have an uncanny knack of remembering useless information but I think this was the time we drove down to Worcester in a Cadbury’s Lucky Numbers Assortment van which produced some alarming noises from the rear axle area - we weren’t sure if we’d get there and back at all. And I can even remember that van’s registration : 148EON. That was the first of two occasions that I spent time on the Metal Box machine and I remember that the company provided excellent facilities for the operators : there was even a small kitchenette, presumably for when their operators worked extended hours. Not without some justification did one of my colleagues wearily say (doubtless after another all-night session) that we ought to adopt as “our tune” the old Welsh hymn “All Through the Night”.
My personal log of those days is full of entries recording machine problems, usually meaning no useful work could be done. I think one of the engineers told me that the electronics used small electric currents as signals, as opposed to the more usual arrangement of using voltage pulses; currents were far more susceptible to dubious connections and when you think of the thousands and thousands of push-fit edge connectors in all those circuit boards it’s perhaps not surprising that we had problems - I don’t think any other computer manufacturer did this.
The failures came in various forms. Sometimes the Flexowriter we used to communicate with the computer failed to respond when we pressed the switch on it’s side to allow it to accept commends : when this happened an engineer would appear, turn a key on the control panel one notch, tweak a red button and then turn the key back - normally, this worked. In theory, us mere operators weren’t supposed to do this - enough said (well, they always DID leave the key in the lock).
Other times we had problems with individual peripheral devices : a tape drive wouldn’t load a tape or a tape punch refused to work. This might affect whatever was trying to use it at the time but the rest of the machine carried on as normal. An example : Which presumably meant that magnetic tape deck B was no longer useable so whatever program was accessing it at the time had failed; I assume that the numbers following were some diagnostic information which the engineers understood. What the “PER MTF” command below did I have no idea - presumably it wasn’t connected to the MTB failure.
More serious were failures of the magnetic drum which usually stopped everything. The one we really dreaded was when a parity error occurred in the core memory - the whole machine would seem to pause briefly, tape drives ceasing, card reader stopping, and then the Flexowriter would give three rings on it’s bell and then print the dreaded message : ( CORE PARITY FAILURE ) 1234 ... after which there were three more rings on the bell and then the machine fell silent. This inevitably meant engineers being required and often heralded a long period of down-time. Rather oddly, the message sometimes came as : ( CORE PARITY FAILURE ) NOT FOUND ... which always puzzled me - how could you know there was an error without knowing where in the memory it was? I mean - you must have known what memory address you trying to use at the time. I never did find the answer to that one (and I don’t have an actual example of this to include here !).
My records also shown that in late March Leighton Jones himself (no less) went off to Norwich one evening to try to catch up on some of our backlog of work, presumably after lengthy breakdowns at Cadbury’s. I think that Norwich Union also had an Orion but does this mean that the Metal Box Company and the Newman St. Orions were both down at the same time as ours ? Quite possibly, given the state of things at that time.
So what did we do when the Orion actually was working ? My memory is that the main daily application was the “Sales Run” - which meant running a sequence of programs whose names were “1SALE”, 2SALE” ... up to “7SALE”. Program 1SALE read punched cards, usually several metal card trays of them; I have a memory that these cards were punched elsewhere (quite possible in the building over the road which we referred to as “Franklin” - I think I recall using a trolley to transport a load of these trays through “Number 2 Lodge” on Bourneville Lane.) I assume that these contained details of actual sales, and one of the subsequent programs updated customer information about these - presumably as some sort of Sales Ledger. There were certainly five “BiFiles” (Basic information files ?), one for each day of the week and woe betide us if we used the wrong one. Another utterly useless piece of information that I still cannot forget is that there was one account that always threw up a “duplicate” error - the same one each day; I have no idea who it was but I can tell you that the account number was 90L302. Why can’t I remember useful things instead?
Near the end of this sequence was the invoice printing run itself : 7SALE - see below for some of the bizarre procedures that we had to use for this. The whole sales run took a few hours to complete and it was always a relief to get to the end of it.
There was a similar procedure for Credit Notes (hopefully used rather less !) which followed similar steps but the programs were called “1CREDIT” etc. and - un-surprisingly - it printed credit notes instead of invoices.
Other applications were in process of development and I well recall trying to test programs that handled “Wait Orders” though I never quite found out what these were. Small cardboard boxes would be delivered to us, each usually containing one or more rolls of punched paper tape, one roll being the program which had to be loaded (and compiled ?) and the other the data with which to actually test it. Instructions were on printed forms on which we added the results of the test. I rather think that some of our replies were slightly irreverent ... We did the testing as and when we could fit it around the production work but in time, boxes would appear with a red “URGENT” sticker stuck on the outside; later again a few started coming through with two such stickers - we were supposed to process these as soon as possible and probably did .....
The actual editing of program code was somewhat basic. For much of my later programming career program source code was kept on the computer and changing lines of code was done with a text editor not unlike a word processor . It was a bit different in Orion days. A program was initially typed onto a long spool of paper tape and later changes were made by physically cutting the tape (with scissors !) and inserting new code by literally adding new bits of paper tape. To splice these together programmers used lengths of a sticky version of the paper tape which straddled the physical join either side and which was pressed down into place while the two cut ends were held in a sort of metal jig. Paper tape came in many colours and after much editing a program tape spool could contain a rainbow assortment of colours. And yes, those sticky bits used to join bits of paper tape did sometimes come apart - usually while the tape was going through the tape reader. Sometimes these program tapes grew to a spool several inches across with a kaleidoscopic range of colours, and it could take a very long time to read it all in. I still remember one program - I have no idea what it was supposed to do but it could take an hour to read the tape and sometimes we ran out of core before it was all in ! It was called CADJVR.
This is what started my own interest in the programming side of computing : exactly what did these people actually write to make the Orion DO something ? In the later stages of this 6-month employment I took a few tentative steps to find out, initially talking to one or two of the programmers and then borrowing a programming manual from one of them “just for the weekend” (I still have it ..... sorry, someone). Although I didn’t appreciate it at the time the programming language - called “Symbolic” I think - was really little more than machine code plus the ability to give names to data locations. So you could call a particular 1-word memory location “A1” and then to set this to a value of 25 you’d write : 14 A1 25 where the “14” was the actual machine code for “copy the numeric value in y (the third element on the line) to address x (the second element) i.e. what you’d previously defined as memory address A1. In other languages, and in later years, this could be written as :
MOVE 25 TO A1 ( COBOL - to be avoided if at all possible) LET A1 = 25 (BASIC - many versions)
Inevitably, I wanted to try this for myself and by now we were working daytime and evening shifts; sometimes there was little work to do in the late evening and so I quietly wrote a tiny program to see if I could achieve this. Presumably I used a tape punch (somewhere ???) to type the actual instructions and the modifications that proved necessary later. That first program wasn’t anything dramatic : it simply looped a number “n” upwards from 1 to 50, printing for each value of “n”, the number itself, the number squared, cubed, and it’s fourth and fifth powers. I discovered, early on, that the capacity of the Orion word (as a numerical value) was exceeded before “n” reached one particular value when calculating the fifth power; the same thing happened at a higher value of “n” with the fourth power. It was thus necessary to stop printing those particular powers before this happened.
Eventually, one night, my program worked, and I still have the program listing, the compiler’s report on it, and the final output listing. It was a great day for me ! It also solved a major problem in my wider life : what was I going to do after I finished my time at university ? Uncertainty and worry about this was part of the cause of my problems the previous year, but this brief - and totally unauthorised - excursion decided me beyond any doubt : I was going into programming as a career, no matter what any other member of my family (or anyone else) thought.
But in the meantime I still had to finish my summer as an operator and that still meant 1SALE ... and all the rest, including the business of printing all those invoices etc. as well as my own surreptitious list of numbers and their powers, from 1 to 50. Back to the world of operations, then.
Operating those printers was quite an art in itself. All printer paper came as fan-folded continuous stationery and had to be carefully fed through the print mechanism, the perforations on each side having to be carefully dropped onto the tractor feeds, one such feed each side above and below the printer mechanism - so there were four places where you could get this wrong. And if you did get it wrong you’d probably end up with the celebrated “paper wreck” : many - sometimes a great many - sheets of paper all jammed together in a massive tangle as the lower pair of tractors continued to force paper up into the print mechanism but the upper two no longer pulled it clear. It could take a long time to remove all the pieces and if you missed a bit then the paper would probably wreck again when you tried to resume. If you were very lucky - and the paper came off all four tractor feeds at the same time - then you wouldn’t have quite that mess to undo. You’d simply find that several dozen (or several hundred) pages of printing had all gone onto a single line across a single sheet of paper. In other words, a large solid blob of ink on one page but you’d still have to restart the print run again.
An interesting procedure was needed when one box of stationery was running out and there was still a lot printing to go - this was the case with the long print runs and the invoice print mentioned above was the usual case. The technique revolved around some “paper joiners” : strips of paper, lightly gummed on one side, whose edges were perforated the same way as those of the actual printed stationery and whose width matched it. Each joiner was four perforations long, so when a new box was going to be needed you did as follows :
If you got it wrong a paper wreck usually followed. Re-starting a print run such as invoicing meant re-running the print program and inputting a short length of paper tape with some identifier as to where to restart from; 7SALE gave regular “updates” on it’s progress (note the time and date) : For no reason at all I can still remember that you typed a line : L1.19 = something (possibly the most recent of these Block numbers) as part of this We must have had access to a paper tape punch to create these restarting pieces but I don’t recall where it was. I have a sneaking feeling that when dementia finally claims me, I may well forget my name, my wife’s name, my children’s and grandchildren’s names, and probably most other things as well, but I will still know that L1.19 was the parameter for re-starting the Cadbury’s invoice print program back in 1965.
A possibly apocryphal story (and I wasn’t involved) : with a lengthy print run it was allegedly possible to join two boxes of paper together (see above) and then hurry down to the games room for a quick game of snooker; one operator went first and phoned back to the computer room - the other answered it and then put handset down near the printer and joined his colleague. It was thus possible to enjoy the game while regularly listening on the phone to ensure the printer was still printing. But as someone once said wistfully “ ... of course the print mechanism may still be running but that doesn’t mean that there’s actually any paper going through it .....”
There was also the matter of telling the printers how to handle “throw to top of next page” i.e. if a document - for example an invoice - finished part-way down a page how to handle the “move forward to the top of the next page” instruction. Different types of documents had different page lengths so this was a real problem, and it was overcome by the use of the (in)famous “Mylar loops”. Mylar was a sort of plasticised paper tape which had the sprocket perforations along it’s length but - as supplied - no other perforations. What you did was to cut a length of Mylar tape which had exactly the number of sprocket perforations as print lines of the document concerned. You then used the same type of “paper tape joiners” that the programmers used when editing program source code to create a loop of this exact length of Mylar. Then you used a hand-punch to make a single hole in track one of the loop at some point. Simple eh ?
The obvious weak link was the Mylar loop itself. The most usual problem was when it broke - usually at the join. When that happened the printer would simply go on feeding paper for ever without printing anything, at least until an operator noticed something amiss and pressed the relevant stop button. Or the tape could become worn with endless looping and slip off the sprocket feed; or the sprocket holes could get worn and adjacent ones “join together” so that page feeds still happened but not at the top of actual pages ... The range of possible disasters was wide ! And now printers simply feed sheets of A4 paper without even trying.
Now the Orion was a multi-tasking machine (though I’m not sure that this particular phrase was used then) so it could do more than one thing at a time. More specifically, it could run more than one program at a time, given sufficient memory to do so. (Other resources - paper tape readers/punches, magnetic tape drives, printers, etc. obviously had to be shared as well but core memory was usually the real deal-breaker.) The Orion used to regularly print on the Flexowriter what each job was using, usually in the format :
This was often irrelevant if only one program was running but if we were trying to run one of the sales programs, and compile a test program at the same time, a situation could arise where we could see ourselves running out of core storage. Drum storage was rarely a problem as there was plenty of it, but with only 12k of core we could see one or other of the competing jobs exceeding the core available; add together the “CORE nnnn” of one job with that of another which was steadily increasing (typically with a test job) and sometimes the result was getting near the maximum. The art lay in trying to avoid this but sometimes we were caught out : what to do ? and which job to get rid of ? And what if we tried to start something new and the machine was already “full” ? In that last case it came back with “Oh come on mate, with what we’re already doing for you ??? Get lost” Or, in Orion-speak : Which at least uses fewer words.
Obviously, production runs normally took precedence over testing, but there was still the decision of exactly how to terminate a program once it was running. In NASA terms the phrase “mission aborted” can sometimes be heard but - perhaps with the delicate nature sometimes associated with that word - the two procedures used in Orion-speak were “Abolish” and Abandon”, usually abbreviated on the Flexowriter to “ABO” and “ABA”. And it was considered essential to use the correct one : at one point a questionnaire (almost a “test” in school terms) was produced giving various scenarios and asking, in each case, “Do you ABOlish or ABAndon ?” I had no idea (and most of the other operators probably didn’t either) but in my case I didn’t have to answer as I was about to finish my 6-month term there anyway.
In later years, when using DEC hardware with true time-sharing, and where remote users were charged actual money per hardware usage, I could appreciate how such a difference could indeed matter. A situation could arise when someone’s program had to be terminated due to factors beyond their control and no charge would thus be made; equally, though, if a user program got “into an endless loop” and was clearly going to run for ever then it was legitimate to kill it but still charge for the machine time used. (Early DEC machines used the concept of “kilo-core-ticks” whereby the charge was a product of how many “k” of memory was used times the number of “ticks” on the computer’s internal clock.) But the Orion was, almost by definition, going to be used by a single organisation only so such charging procedures were probably irrelevant. I’ll probably never when I should have ABO’d or ABA’d !
Also in the DEC era, time-sharing was an extremely sophisticated procedure. Each job could run till it needed a time-intensive operation to perform - typically waiting for a line printer to actually print a line of data ( a geological age in computer terms) - so it was suspended while this happened and some other job “got the machine” until it too hit a similar block. Many jobs could thus share the actual computer with a constant stopping and starting of each as these brief interruptions happened. It was all done so cleverly and so fast (interruptions were measured in milliseconds) that all the jobs appeared to be running all the time I have a vague memory that the Orion’s “multi-tasking” was pretty basic : each job had a fixed time slot and “got the machine” during that time, irrespective of any waiting operations necessary. And that time slot was one minute - not some milliseconds. I’m sure I can remember when two jobs - both using 3 or 4 of the tape drives - were running and one set of tapes would whirr away and operate while the others stayed still; after a minute there would be a frantic flashing of lights on the control desk and then those tape drives would stop and the other set would come to life.
As an aside, what were we paid for doing this job ? I was taken on as a “temporary worker” so I had no holiday entitlement but I did receive the same basic wage as the other operators. I seem to remember that at some point in my 6-month stay we were given a pay rise and I’m fairly sure that our weekly pay went up to about £12.35 (or rather, to £12-7-6d in those pre-decimal days). When you consider that the National Living Wage is now (June 2017 outside London) £7.85 per hour you can see how far things have come. Of course, in 1965 a pint of beer cost the equivalent of 6-9p and a white unsliced loaf was 6-7p.
The following summer - 1966 - having done my final uni year and with one last exam to take (or to be honest : re-take) I was at home again and Cadburys rang to ask whether I could do a few weeks of operating to cover people on holiday. I agreed and thus once again found myself in that familiar environment but with significant changes afoot. Next door (I think there was a connecting door) another big room was being prepared for the arrival of an ICT 1900-series computer which I assume swiftly took over the work done on the Orion so far. I also assume that the Orion was then de-commissioned so Cadburys can’t have had much value out of what must have been a major investment.
Soon afterwards, I took and passed that final exam, and a few weeks later returned for the last time to my university. On a Wednesday afternoon I duly graduated with a degree in geology and I’ve hardly looked at a rock since. I spent Thursday recovering from the graduation night party, drove home on the Friday, and the following Monday I started work as a trainee programmer at ICT (later ICL and then Fujitsu). And that was the start of an software career that lasted until 2002 when it ended abruptly and somewhat violently. (It actually ended in an Industrial Tribunal courtroom but that’s another story). But just look how it all started !
Thereafter, and now in 2003, due to circumstances that have never been satisfactorily explained I found myself running first one, and then two, community bus companies - an interesting career change indeed. But with Grant Funding drying up at the time we had to start operating fully commercial bus routes which meant me starting a third and totally new company. While casting around for a suitable name for this new venture, and perhaps in a nostalgic moment, I toyed with the idea of “Orion Transport Services” - however this didn’t impress my co-founders and so Severnside Transport Ltd came into being. But it would have been nice to have bookended my career with the name Orion .........
Doug Howat Thornbury, Bristol July 2017
PS And as for what’s happened to Cadburys since then, well ........................... Date : July 2017 This exhibit has a reference ID of CH44291. Please quote this reference ID in any communication with the Centre for Computing History. |
|
